Fix offline peer dependency resolution by synthesizing bun's manifest cache - #103

A "<workspace-name>/<pkg>" lockfile entry records its file-dependency path
relative to that workspace's directory, but bun.nix paths resolve from the
project root — so a vendored tarball under packages/app rendered as
./vendor/pkg.tgz (missing) and a sibling workspace's ../app/vendor/pkg.tgz
escaped the root entirely.

Factor package building out of convert_lockfile_to_nix_expression into
build_packages, and rewrite CopyToStore paths for entries nested under a
workspace (longest workspace-name prefix wins) with lexical ././..
normalization.

…network

Two hook fixes for failure modes found installing opencode offline. Both
stem from the same bun behavior: any drift between package.json and
bun.lock makes bun re-resolve the affected dependencies, and re-resolving a
git/github/remote-tarball dependency downloads it unconditionally — fatal
in the sandbox no matter how complete the cache is.

- Detect trustedDependencies / patchedDependencies drift between the root
  package.json and bun.lock and fail with an actionable message (refresh
  bun.lock, regenerate bun.nix). Projects routinely commit a lockfile whose
  copies of these sections lag package.json (opencode's does); without the
  check the drift surfaces as a wall of ConnectionRefused errors at resolve
  time with no hint of the cause.
- Leave catalog: references pointing at non-registry specs (github:, git+,
  tarball URLs, file:) unrewritten. bun resolves those natively from the
  lockfile's catalog section; rewriting them to their resolution registered
  as a changed spec and forced a re-resolve.

The hook now runs the prep script whenever bun.lock exists (previously only
when it contained catalog: refs), so the drift check covers every project.

Runs resolve-catalog.ts against three inline fixtures: drifted
trustedDependencies/patchedDependencies must fail with a diagnostic naming
the drifted entries, identical-but-reordered sections must pass, and
catalog: refs must be rewritten to exact versions except when they resolve
to non-registry specs. The drifted fixture has no catalog: refs, pinning
that the check runs for plain projects too.

…eator

Introduce a programs/ cargo workspace with a shared bun2nix-core crate:
vendored bun Wyhash11, the bun cache-folder-name port, and verbatim
structs + serializer + multi-version builder for bun's binary .npm
manifest cache format (bun-npm-manifest-cache-v0.0.7). Rewrite
cache-entry-creator from Zig to Rust on top of it, keeping the symlink
behavior and adding a manifest mode that turns EntryMeta JSON into .npm
cache files. Nix package builds updated to build from the workspace.

The dependency-graph metadata bun stores inline in each npm lockfile
entry mirrors the abbreviated registry manifest, so the deserializer
rebuilds a per-version VersionMeta from it with no network access.
Default-registry entries render a manifest attr in bun.nix (tarball URL,
dependency groups, bin/os/cpu, install-script flag) for the offline
manifest cache to consume downstream.

Collect EntryMeta records from bun.nix manifest attrs and run
cache_entry_creator manifest to write the .npm files bun consults at
resolve time, merged into the dependency cache. The install hook exports
BUN_MANIFEST_CACHE=2 so bun reads the on-disk manifest cache instead of
hitting the network. Manifest-less bun.nix files yield an empty cache
and build as before.

…nity#71)

react-dom@19 peer-depends on react; bun.lock is excluded from the
fixture source, so bun must resolve peer deps from the synthesized
manifest cache — the code path that previously fell back to the network
and failed in the sandbox. flake.nix now skips auto-importing fixture
bun.nix files (they are package expressions, not flake-parts modules).
Also pins the manifest format version as a tripwire.

…ity#71)

Key each package's .npm manifest by the registry bun will compute at
offline-install time. A new bun2nix-core config module parses
project-local bunfig.toml/.npmrc contents (.npmrc overrides per key)
and ports bun's scope_for_package_name; global/env/CLI layers are
deliberately ignored because the Nix sandbox's bun cannot see them
either. Non-default entries carry a registry attr inside their bun.nix
manifest block, cache-entry-creator groups by (name, registry) and
writes <wyhash(name)>-<wyhash(registry)>.npm with the registry's
url_hash in the header, and the wasm CLI passes the two config files'
contents across the boundary (no filesystem access in core).

…ure)

End-to-end guard: the fixture pins react/react-dom to
https://registry.npmmirror.com via a committed project-local
bunfig.toml; bun.lock is excluded from the source, so sandbox bun must
find the registry-keyed <hex>-<hex>.npm manifests under the url_hash it
derives from that same config — proving the generation-time key matches
byte-for-byte.

…os/cpu

Pre-release versions were stored tag-stripped in the releases map, but bun's
find_by_version only searches prereleases when the queried version has a tag,
so any pre-release pin (e.g. nitro@3.0.1-alpha.1) missed the synthesized
manifest and fell back to the network. Parse the full
major.minor.patch[-pre][+build] form with a port of bun's Tag.parse state
machine, intern pre/build tags (Tag.eql compares wyhash11 of the pre span),
and split versions into the releases/prereleases maps, each sorted ascending
with bun's numeric-aware order_pre (find_best_version scans from the end).

os/cpu parsing now ports bun's Negatable accumulator: "any", "none",
"!name" negation, and unrecognized-value handling, all of which bun writes
back into bun.lock metadata.

With minimumReleaseAge configured (e.g. opencode's bunfig.toml), bun's
manifest cache load rejects any manifest whose has_extended_manifest flag
is unset — it demotes the entry to expired and schedules a network refetch,
which is fatal in the sandbox. Set the flag: our zeroed
publish_timestamp_ms values read as "published at epoch", which passes
every age gate — the right answer for lockfile-pinned versions.